home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 682 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.2 KB
  1. Date: Mon, 4 Jul 1994 15:09:22 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: available keys
  4. To: gem-list@world.std.com
  5. In-Reply-To: <UUCP.773336278@mettav>
  6. Message-Id: <Pine.3.87.9407041522.A11977-0100000@grad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10. Annius:
  11.  
  12. )> There was discussion of busy-waiting... well, SOMETHING has to busy wait,
  13. )
  14. )Not so.  The mouse generates an interrupt when it is moved.  So the OS
  15. )doesn't need to do any checking while the mouse is not moved;  the
  16. )other approach would.
  17.  
  18. If you used a 1-pixel rectangle, then your program would be interrupted 
  19. every time the mouse moved.  This wouldn't take a whole lot more overhead 
  20. than the interrupts that the OS gets from the hardware.
  21.  
  22.  
  23. Vincent:
  24.  
  25. )vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  26. )CLRHOME          Move to top of window    <<none>>
  27. )shift BKSP       same as normal backspace  ...
  28. )^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  29. )I agree. I suggest that the difference between BKSP and shift BKSP would
  30. )be: BKSP can't delete CR while shift BKSP can (like in Edith).
  31.  
  32. Shift-Backspace should do the same as Backspace, and CR is the same as 
  33. any other character that can be deleted.  Are you putting physical 
  34. returns at the ends of your lines within paragraphs?  Ick!
  35.  
  36.  
  37. Baker:
  38.  
  39. )buttons required to use an untopped window (like in the desktop). Does
  40. )everyone agree with me that the mswindows behaviour of topping _and_ 
  41. )activating a button is undesirable?
  42.  
  43. That behavior is not only undesirable, but irritating in the extreme.
  44.  
  45.  
  46.  
  47. One recurring theme I see coming from some of you is that you seem to 
  48. want to make drastic changes to the way the GEM interface operates on a 
  49. fundamental level.  Putting dialogs into windows is great, IMO.  But 
  50. making other changes like (For things other than tool boxes) not topping 
  51. windows when they're clicked in not only confuse and frustrate people 
  52. (myself included), but they often make simple things (like topping 
  53. windows when you WANT to) difficult.  
  54.  
  55. GEM is its own user interface, with its own peculiarities and traits and 
  56. features that make it distinct from (and some times superior to) other 
  57. GUI's.  Let's not go mucking that up in ways that we don't need to.  
  58. Adding good features is one thing, but let's not go crazy with this.  
  59. Demanding that people start going against the basic design of the 
  60. operating system is not reasonable... at least not until these features 
  61. become part of the real OS.
  62.  
  63. I want my apps to work on people's computers without a lot of crap.  I 
  64. don't want to have to confuse the user by having them install a new 
  65. program in the AUTO folder to take up more memory just to add a few 
  66. features to the OS, especially if they have to pay extra for this 
  67. utility.  When standards boards start becoming police and judges that 
  68. demand that I do something in my app that is not only not part of the OS, 
  69. but difficult or wasteful to implement or interface with, then things 
  70. have gotten way out of hand.
  71.  
  72. Let's be sensible about what we put into our standards, shall we?  It's 
  73. wonderful to supply code for dialog-in window things that add extra 
  74. functionality, but let's not require it, even in the unlikely event that 
  75. the programmer were to make it easy to implement or interface with.
  76.  
  77.  
  78.  
  79.